Steps to Access Malaysia’s CN2 for Developers and Common Troubleshooting Methods

Introduction: This article is aimed at developers deploying in Malaysia or connecting to China Telecom CN2, providing practical steps from preparation and connection to performance verification and troubleshooting of common issues. The content is focused on practical technical operations, making it easy to quickly diagnose and optimize.

Preparatory Work and Needs Assessment

First, assess business requirements: Bandwidth, latency, redundancy, and compliance requirements. Confirm the target traffic type (unidirectional/bidirectional), whether a fixed public IP is required, BGP multi-homing, or just for backup. Clarifying latency and availability SLAs helps in choosing the appropriate connection method.

Select access method and physical link

Common ways to connect to CN2 include direct dedicated lines, IP forwarding, and virtual tunnels (GRE/IPsec). In Malaysia, the physical link can be determined based on the location of the data center, the submarine cable routes to China, and the support from local ISPs, with priority given to low-latency and stable transmission paths.

Considerations for operators and data center locations

Choose an upstream operator or proxy node with CN2 connectivity, giving priority to data centers with established interconnections in major cities such as Kuala Lumpur or Penang. Pay attention to whether the peer supports requirements such as BGP communities, route filtering, and MD5 verification.

Obtaining network resources and configuring BGP

Key Points of BGP Configuration: Prepare the Autonomous System Number (ASN), public network prefix, peer IP address, and dial-up password (MD5). Apply for single or multiple BGP sessions based on the plan, and establish local priority, AS-PATH, and prefix-list policies to prevent route leakage.

Routing Policies and Community Settings

Use routing policies to limit advertised prefixes and accepted prefix lengths, and set local-preference and community values appropriately to control traffic backflow. Common peer communities can be used for traffic engineering and downstream filtering.

Tunnels, Security, and Network Isolation

For scenarios where direct physical equivalence is not possible, GRE or IPsec tunnels can be used to connect to the upstream CN2 node. Pay attention to MTU configuration, performance losses caused by encryption, and tunnel stability, and use MPLS/VPN solutions to achieve tenant isolation when necessary.

Testing and Performance Verification Methods

Use traceroute, mtr, ping, and BGP routing tables to check paths and hops before and after going online ； Measure packet loss and jitter to verify bidirectional routing consistency. Conduct end-to-end high-volume testing to verify link stability and throughput performance.

Common Faults and Troubleshooting Methods

BGP cannot be established: Check the peer IP, ASN, password, and firewall port (TCP 179) ； Confirm that the MTU matches the tunnel parameters. When a route is not declared or is filtered, review the prefix-list and route-map. High packet loss or latency requires investigation of the link, packet loss points, and congestion.

Other common issues and solutions

DNS resolution errors are common due to path changes or restrictions from intermediate devices; check the resolution path and recursive servers ； When firewall policies prevent traffic from passing, connection tracking should be recorded and necessary ports should be opened according to the policy. Logs and packet captures are key to identifying problems.

Summary and Recommendations

For connecting to Malaysia’s CN2, it is recommended to start with small-scale testing first to clarify the BGP policies and security boundaries, and to use monitoring and alerts to track routing, latency, and packet loss. Standardized configuration and change management can significantly reduce the risk of failures. When encountering cross-domain issues, prioritize collaborating with upstream engineers to troubleshoot.